home *** CD-ROM | disk | FTP | other *** search
Text File | 1989-03-15 | 3.4 KB | 87 lines | [TEXT/MPS ] |
- MacTutor Article Notes:
-
- Previous articles
- Eor & copyBits
- Mathematically elegant algorithm
- Computationally inefficient
- Assembler routine
- More direct rotation
- Optimization
- peephole methods
- no consideration for algorithm
- This article
- Complete set of rotations
- new algorithms
- optimized techniques
- no claim to be the end
-
- Why talk about rotation
- Mac is graphic, so we may do them frequently in graphic applications
- awkward problem, but easy to relate to
- must take individual bits from a column in the source bitmap
- to generate bytes and words for destination bitmap
- this requires lots of bit orientated operations
- Efficient strategies can cause large changes in the relative
- cost to perform these operations, as prev articles show
- Allows us to demonstrate technique
-
- This article's focus
- Using Macros to develop efficient set of similar routines
- Some more coding tips
-
- Bitmaps and their rotations
- Complete set of rotations
- rotate left or right 90°
- mirror horizontal or vertical
- rotate 180°
- flip across the diagonals topLeft to lowRight, FL
- lowLeft to topRight: FR
- final state, no rotation at all.
- Rotation state
- Application may take user input as an object
- Apply multiple rotations
- User loses track of original orientation
- rotation state tells where object is, after repeated rotation xforms
-
- Simpler to explain just one casein single article,
- but let's get ambitious.
- Goal to create routines with common manipulation Macros,
- so that as we develop them, optimizations and bug fixes in one rotation routine
- are applied consistantly to other symetrically related operations
- Macros allow us to have optimally unwound code emitted for each routine,
- with the structural symmetries inherent in them preserved at the source
- code level, hopfully assuring a more structured and correct implementation
-
- Bitmap is defined within any Rect to the exact bit
- image in the map is always aligned to the anchor point at the top left
- bitmap rows are rounded up to ta whole word boundary
- for more efficient bitmap manipulation
- These extra slop bits, when rotated, can complicate the rotation algorithms
- Efficient to pick a block of bits in registers
- carve off column bits to build a row byte or word
- we have 8 32 bit data registers, D0-D8 to do bit manuplications with
- they can hold a total of 16 words in their high and low ends
- It would be nice if we can work on blocks of 16 words at a time
- we can't require bitmaps to have rows and columns on 16 bit boundaries
- so, we must contend with slop bits on the right and the bottom of the Rect
-
- Some pictures can show how these extra bits are rotated
- by the 8 possible rotation transformation states
- { rotation pictures }
- The processing iterations
- start in top left
- get a block (for rotation)
- process words down the block
- carving off bits from the left to build output word
- bits forward or reversed
- go to next block of the same rows
- at end of row, drop to next set of rows, and process again, left to right
- finished at end of column
- slop bit handling
- slop bits are left on the right, left top and bottom of the resultant Rect
- slop bits on the bottom are delt with by not storing words beyond the end
- Slop bits in the bitmap on the right are easy,
- the destination bitmap requires them
- Slop bits in the bitmap on the left are handled after the bitmap has been generated
- by shifting the resultant bitmap left by the number of slop bits
-